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1.0 


HASP - VERSION 3.0 


A new version of The HASP SYSTEM -- HASP-II, Version 
3.0 -- is now available from the Program Information 
Department (Type III program number 360D-05.1.014). 


This release 1S a major revision of, and a replacement 
for, the current HASP SYSTEM (HASP-II, Version 2.3). 
All users of record of the current HASP will receive 
automatic notification of availability together with 
Ordering instructions for Version 3. 


The following is a summary of the major support fea-. 
tures and incremental improvements contained in the 
new release. Additional details concerning the gener- 
ation and use of these items are contained in the 

HASP SYSTEMS Manual distributed with the HASP-II, 
Version 3 System. 


New Support Items 


@ System/370 Support - Version 3 will operate in 
conjunction with OS Release 20 which provides 
support: for the IBM System/370. 


° 2770 Support - Version 3 contains support for 
the IBM 2770 Data Communication System as a 
remote batch workstation. 


@ System/3 Support - A workstation program to 


-support the IBM System/3 as a HASP MULTI-LEAVING 
workstation is now provided. 


@ 3211 Printer Support ~- HASP device support has 


« now been expanded to include support for the 
IBM 3211 Printer (when associated OS Support 
is available). : 


® 3330 Disk Support - The HASP direct-access 
allocation facilities have been expanded to 
accommodate the increased capacity of the IBM 
3330 Disk Storage (concurrent with OS device 
support for 3330). 


—€ 


we 
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@ 2260 Support - BaSic support is now included to 
operate the IBM 2260 Display Station as a local 
HASP console. 


Incremental Improvements 


@ system Restructure - HASP has now been segmented 
into multiple functional assembly modules. This 


restructuring includes a complete re- numbering of 
Che HASP source statements. 





e Overlay Structure - An overlay capability has been_ 
added such that selected sections of HASP may 
optionally be made resident on direct-access 
storage and fetched into a dynamic area within 
HASP to perform their reguired functions. 


e Improved Operator Command Facilities - The HASP 
Operator Command Processor has been rewritten to 
provide a more flexible command format, a more 
powerful command set, abbreviation capabilities, 
and full use of the overlay capability in HASP. 





@ Improved OS Console Interface - Installations may 
now utilize OS console support rather than the 
HASP support and still retain HASP Remote Console 
Support, direct entry of HASP commands, short form 
REPLY, input stream HASP commands, and the auto- 
reader feature (Release 19 or later for MFT Systems). 


@ Punch Special Forms - Special forms may now be 
specified for SYSOUT data sets which are to be 
: punched. 
@ Improved SYSOUT Forms Routing - Users may optionally 


Gause grouping of SYSOUT data sets by forms type to 
minimize printer/punch setup time. 


@ §§§§ MFT Dynamic Dispatching - The Dynamic Dispatching 
capability in HASP, previously restricted to MVT 
Systems, may now also be used with MFT eyerens 
(Release 19 or later). © 





HASP NEWSLETTER #13 


Page 1.2 


Elimination of OS Writer Requirement - HASP now 
optionally provides a minimal module to interface 
to the OS job queue which eliminates the pre- 
vious requirement for a resident OS writer in 
both MVT and MFT (Release 19 or later for MFT 
Systems). 


Execution Job Batching - Jobs may now be auto- 


matically grouped by class and passed directly 
to an executing job such as a one-step monitor 


or other direct job processor. 


Improved SPOOL Disk Allocation - Space on SPOOL 


disks is now dynamically allocated by logical 


track groups rather than by physical cylinders. 
Each bit in the HASP allocation map now repre- 
sents a HASPGENable number of. direct-~access 
tracks. 3 


Non-MULTI-LEAVING Terminal Console Support - Users 
at non-MULTI-LEAVING remote workstations (2780, 
2770, 1978, STR Model 20, etc.) may now receive 
responses to HASP commands submitted through the 
remote card reader. 


Improved SMF Compatibility - Provision has now 
been made to allow SMF to count I/O requests for 
pseudo devices. 


Priority Aging - Installations may optionally 
cause the priority of jobs to increase in propor-~ 
tion to the length of time the job has been in 
the system. | 


Variable Buffer Pool - The number of buffers in 
the HASP Buffer Pool may now be dynamically varied 
by changing the HASP region or partition size. 


Additional Print Control - The operator now has 
the capability to both forward and backward space 
print data sets a variable number of pages. Print 
jobs may also be suspended during processing and 
resumed at a later time. | 


Withdrawable HASP - An operator command is now 
provided to cause HASP to withdraw from the system 
leaving OS in an operational state. 
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e Maintenance ~- All previously reported problems 
have been corrected in this version. 
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HASP - QUESTIONS AND ANSWERS 


What is the current status of the HASP SYSTEM? 


HASP 1S a Type-III program, number 360D-05.1.014, 
and has a program service classification of A. 


What is the latest version of HASP? 


Version 3.0, which was announced as available 
on February 26, 1971, is the latest release 
of HASP. 


How long will the previous version of HASP be 
supported? 


Version 2 of HASP will continue to receive Class 

A maintenance support when used with any supported 
release of the Operating System prior to Release 
20. : 


Will Version 2 of HASP be supported when utilized 
with Release 20 of the Operating System? 


No... Installations on Release 20 of the Operating 
System should use Version 3 of the HASP SYSTEM. 


Will Version 3 of HASP be supported with releases 
of OS prior to 20? 


Yes... Version 3 will be supported when used 
with any previous version of the Operating System 
which is, itself, supported. 


Will Version 2 of HASP operate correctly with) 
Release 20 of OS? 


Preliminary field reports indicate that Version 

2.3 appears to operate correctly with Release 20 
of the Operating System. As indicated in 2.0.4, 
this combination will not be supported. 
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2.0.10 


Q: 


A: 


Will the current HASP MULTI-LEAVING workstation 
programs operate correctly with Version 3? 


Yes... The various workstation programs avail- 
able with Version 2.3 should operate correctly 
with Version 3. The workstation programs dis- 
tributed with Version 3, however, have 
incorporated all previous maintenance items, 
include certain incremental improvements and have 
been resequenced for future maintenance purposes. 
All installations should plan to install the new 
workstation programs as soon aS iS possible when 
installing Version 3. 


Can the System/3 MULTI-LEAVING workstation program 
distributed with Version 3 be utilized with 
Version 2.3 of HASP? 


Yes... Although no provision was made in Version 
2 to define a remote System/3, the interface 
defined for any other MULTI-LEAVING workstation 
(with a comparable configuration) may be utilized 
by the System/3. 


Can System/3, Model 6 be used as a HASP 
MULTI-LEAVING workstation? 

No... The workstation program distributed will 
operate correctly only ona System/3, Model 10. 
Does HASP utilize the Rotational Position Sensing 


feature available with the 3330 disk storage? 


No... The direct-access allocation techniques 
implemented in HASP already provide a software 


means of minimizing rotational delay on all 


direct-access devices utilized by HASP. 
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2.0.11 


2.0.12 


Q: 


A: 


Q: 


Can Version 3 be warm-started with SPOOL disks 
created by a Version 2 system? 


No. The SPOOL disks are incompatible between 
nen 2 and Version 3 and must be reformatted 

if switched between systems. ~ Because of the basic 
Similarities of SPOOL disks created by each version, 
a SPOOL disk which has been formatted by one 
version may not be recognized as requiring re- 
formatting by the other version. FAILURE TO 

SPECIFY THE "FORMAT" OPTION WHEN EITHER VERSION OF 
HASP IS STARTED UNDER THESE CIRCUMSTANCES WILL | 
HAVE UNPREDICTABLE, BUT INVARIABLY BAD, RESULTS. 


Under what circumstances can a HASP be warm- 
started with data recorded on SPOOL disks by 
another generation of HASP in which different 
HASPGEN options were selected? 


The two HASP Systems must be the same version and 
must have identical values for the HASPGEN variable 
&BUFSIZE. The only other xequirement is that the 
size of the HASP checkpoint records must be the 
same for both systems. This can be easily accom- 
plished by specifying the same values in both 
systems for the HASPGEN parameters ~- &NUMDA, &NUMTGV, 
&MAXJOBS, S&JITSIZE, &NUMPRTS and &NUMTPPR. A more 
efficient means of compensating, in the checkpoint 
record, for the effect of the variables &NUMPRTS 
and &NUMTPPR can be accomplished via the MICRO-GEN 
facilities of HASPGEN and is left as an exercise 
for the reader. This warm-start procedure is 
generally independent of the release level or 
options selected for the Operating System used 
with each of the HASP Systems. 


The above information is applicable only to 


Version 3 of HASP but similar procedures may be 
utilized with Version 2. 


C 
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2.0.13 Q: Will the 1403 printer, recently announced for the 


System/3, be supported by the MULTI-LEAVING work- 
station program? 


A: Yes... The System/3 workstation program currently 
available with Version 3 of HASP will support 
either model of the 1403 announced for the System/3. 
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HASP ~- MISCELLANEOUS INFORMATION 


If the pseudo printer assigned to the OS writer 
function (&WTR) has been erroneously included in 


the group of pseudo printers defined for symbolic 


unit "A" and the HASP supplied writer is used 

(GWT RPART=*), problems may arise. Any SYSOUT 

data set which is allocated to this pseudo device 
will not be printed. This problem may be circum- 
vented, until another SYSGEN can be done, by 

VARYing this pseudo printer OFFLINE after initiating 
HASP but before beginning job processing. 


The Remote Terminal Support in Version 3 for the 
IBM 2780 Data Transmission Terminal requires the 
following engineering change (and associated and 
prerequisite changes) to be installed on the 
applicable devices: 


Device ECA EC 


“2701 I09 306749 
2703 65 307702 


This change was supported but not required by 
Version 2.3 BUT IS MANDATORY aD. Sooner 2780s WITH 
VERSION 3. 


The HASP SVC to be added to the OS Nucleus for 
Version 3 1s not compatible with the SVC for the 
Version 2 HASP SYSTEM. It is recommended that the 
Version 3 SVC be assigned a number different from 
that of the Version 2 HASP SVC to allow the inter- 
changing of the two HASP Systems. 
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3.0.4 


The use of the SIGN-ON/SIGN-OFF capability of HASP 
RJE 1S in no way dependent on the physical charac~ 
teristics of the communication line utilized (i.e., 


switched/non-switched, dial/leased, etc.). Any 


remote workstation may be generated as "SIGN-ONable" 
by specifying the characters "**" in the line number 
field of the HASPGEN parameter, RMTnn, which is used 
to describe the workstation characteristics. Many 
installations may find it advantageous to require 
all remotes (even those on non-switched lines) to 
submit a SIGN-ON card. In all cases, even if the 
SIGN-ON option is not selected, the /*SIGNOFF card 
should be submitted by remote locations to logically 
terminate operations. 


A problem may arise when operating with the ASB reader 
feature of MVT if sufficient space has not been 
allocated to the OS SYS1.SYSJOBQE data set. If, 
during the interpreting of a HASP job, the queue 
becomes full, the Interpreter will issue the 
message ~- L[EF336I QUEUE FULL AND WAITING - and will 
suspend processing of the job. When space becomes 
available, the job will be reprocessed but may have 
spurious JCL error messages. The problem may be 
circumvented by allocating sufficient space for 
SYS1.SYSJOBQE. 


Installations, using OS Release 19, whose class 
Specifications in the HASPGEN parameter &WTRCLAS 
include any of the classes S, T, U, V, W, X, Y and/or 
Z should reference OS APAR 36685 for restrictions on 
the use of the MSGCLASS parameter. 
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3.0.7 


One of the most misunderstood messages which HASP issues 
is the I/O Error message for remote terminal adapters. 
Probably the most confusing factor is that the messages 
do not necessarily indicate actual hardware errors in the 
normal sense, but are also used to indicate other condi- 
tions which may or may not be relatable to hardware 
errors. The following is a discussion of the most common 
types of line adapter error messages with a brief de- 
scription of the problem(s) implied by each message. 


The basic form of the message is as follows: 
1/0 ERROR ON LINEn uuu,CC,SSSS,1irr,xyee 


where: 


i 


n HASP RJE Line Number. 


uuu = Line Adapter Address. 

SC = CCW op-code used at the time the error was 
detected (for more information refer to "xy" 
described below). 

ssss = CSW Status Bytes (see discussion below). 

1, = Sense Information (see discussion below). 

rr = First significant response character (see 
discussion below). 

XY = Sequence and Command Type. This can be 
correlated to the internal code listed in 
figure 5.15.1 of the HASP Systems Manual to 
locate the actual CCW which was active at the 
time the error was detected as well as other 
CCWs in the sequence being executed. 

ee = Expected Response (see discussion below). 


The following discussion concerns itself with specific 
error messages for EBCDIC BSC terminals and HASP-II 
Version 3.0 only. For STR terminals, the "IBM 2701 

Data Adapter Unit Component Description" (GA22-6864) 
publication should be consulted for a complete discussion 
of the status and sense bit meanings. 


For BSC terminals which employ the USASCII transmission 
code, the following substitutions should be made in the 
EeCRONSS fields listed below: 


Response EBCDIC USASCII 


KOT 37 04 
NAK 3D 15 
ACKI 61 31 


ACKO 70 30 
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In the following discussion, the conventions observed are 
as follows: | 


UPPER CASE LETTERS AND NUMBERS -- indicate fields which 
will appear on the error log exactly as described. 


LOWER CASE LETTERS -~ indicate fields which have not been 
described in any previous example exactly the way that 
they appear in the error log. 


ASTERISKS (**) -- indicate fields which should be ignored 
as they do not contribute to the meaning of the message. 


T/O ERROR ON LINEn uuu,02,0000,00rr, 





94 a8 
B4S 


Explanation: A block sequence error has been detected 
by HASP while communicating with a MULTI-LEAVING terminal. 
This indicates that one or more transmission blocks have 
been lost. "rr" indicates the count that was received 
and "ee" indicates the count that was expected. 





System Action: Any job reading in will be deleted and 
must be re- submitted. 





Operator Action: This represents a very serious error. 
Control records may have been lost which could cause 
partial loss of terminal function. The line should be 
drained ($P) and re-started ($S) as soon as practical. 


I/O ERROR ON LINEn wu ,020C00,0001, {26} %* 


& 


Explanation: A 2770 or 2780 terminal has disconnected 
without signing off and a MULTI~-LEAVING terminal has 
subsequently connected to the same line and is BEECHES 
to Sign on. 


System Action: The previous terminal will be signed off 
( | _ and the Tine disconnected. 


Operator Action: The remote terminal operator must 
re-dial and attempt to sign on again. 
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| 94 
1/0 ERROR ON LINEn uuu,02,0C00,003D, aL 
| B4 


Explanation: A NAK has been received from the remote 
terminal indicating an error was detected at the 
terminal. 


system Action: Normal error recovery procedures are 
invoked. 


T/O ERROR ON LINEn wu 02,0600 0062, {A 


| 70 
1/0 ERROR ON LINEn wu 4024060040070, {2} 61 


Explanation: HASP has received an incorrect 
acknowledgement from a 2770 or 2780 terminal. This 
may indicate that an output device (printer or punch) 
at the remote terminal has become not ready. 

It may also indicate that an output block has been 
lost. 





system Action: The last block is re-transmitted. 


Operator Action: The remote terminal operator should 
check (to any extent possible) for missing or duplicate 
output and request a backspace or restart if the output 
looks questionable. 


I/O ERROR ON LINEn uuu,02,0C00,00rr, 84** © 


° 


| Explanation: Invalid data has been received from 
a 2770 or 2780. "rr" indicates the first significant 
byte received. | 


System Action: Normal error recovery procedures are 
invoked. 
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I/O ERROR ON LINEn uuu,02,0C00,00rr, **** 


Explanation: An invalid response has been received 
from the remote terminal. "rr" indicates the first 


Significant byte of the response. 


System Action: Normal error recovery procedures are 
invoked. | 


I/O ERROR ON LINEn wu y02,0C00,ii {07}, {32 a 


Explanation: An invalid termination character was 
received from a MULTI-LEAVING terminal. "ii" indicates 
the termination character received. 


System Action: Normal error recovery procedures are 
invoked. 


T/O ERROR ON LINEn uuu,02,0D00,0037,84%** 


Explanation: The card reader on a 2770 or 2780 has 
become not ready. This may be caused by a card feed 
error .or by the failure of the remote operator to 
activate the END-OF-FILE switch or button. 


System Action: The system waits for the reader to be 
made ready and transmission to continue. 


Operator Action: The remote terminal operator should 
correct the problem and ready the card reader (insuring 
that the END-OF-FILE switch or button is activated). 
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, 94 
1/O ERROR ON LINEn ona 02,0000,0037,] 24] + 
C6 


Explanation: HASP has received an unexpected EOT. 


System Action: Normal error recovery procedures are 
invoked. 


1/0 ERROR ON LINEn UU, ** ,OEOO pL ix, KK** 


Explanation: A Unit Check has been detected by HASP 
on the Communications Adapter. For more detailed 
information concerning the exact nature of the error, 
the "IBM 2701 Data Adapter Unit Component Description" 
, 7 (GA22-6864) and/or the "System/360 Component 
¢ Description -- 2703 Transmission Control" (GA27-2703) 
: | publications should be consulted. The following 1s a 
brief description of the sense bits for convenience 





only: 
ii Meaning 
80 Command Reject -- "Abortive Disconnect" option 
of the 2701/2703 has been selected and- the 
remote terminal has disconnected without 
Signing off. 3 
40 Intervention Required -- Remote terminal has 


disconnected without signing off and abortive 
disconnect is not selected. 


20 Bus Out Check -- Hardware error. 
,. 10 Equipment Check -- Hardware error. 


08 Data Check -- Line error or hardware error. 


04 Overrun -~- Hardware error or deficiency. 
02 Lost Data -- Synchronization error. 
{ 01 Timeout -- Expected terminal response not 


received by HASP. 
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I/O ERROR ON LINEn uuu,02,FFFF,OOrr, ee 





9 
BS 





Explanation: A block sequence error has been detected 
by a MULTI-LEAVING terminal. This indicates that one 
or more transmission blocks have been lost. "rr" 
indicates the count that was received at the remote 
terminal and "ee" indicates the count that was exnected. 


System Action: Any job printing on the terminal will 
be interrupted, and any job punching on the terminal 
will be restarted. 


Operator Action: This represents a very serious error. 
Control records may have been lost which could cause 

partial loss of terminal function. The line should be 
drained ($P) and re-started ($S) as soon as practical. 





I/O ERROR ON LINEn UUU,yCC,SSSSyLL*K y KKK 


Explanation: An unusual channel end condition has been 
detected by HASP on the Communications Adapter. For 
more detailed: information concerning the exact nature 
of the error, the appropriate hardware component de- 
scription manuals should be consulted. 


System Action: The line is automatically restarted. 
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3.0.8 


Section 10.2.1.6 of the HASP Systems Manual for Version 
3.0 inadvertently omits a mandatory OS SYSGEN require- 
ment for MFT Systems in order to use OS Console Support 
(&NUMCONS=0). The SUPRVSOR macro must contain the 
RESIDNT=(TRSVC,...) parameter in addition to the 
OPTIONS= (ATTACH, TRSVCTBL,...) parameter as documented. 
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4.0 ' HASP-II, VERSION 3 CHANGE GUIDE 


The following section is intended for use as a 
removable manual to serve as a guide to provide the 
user a rapid orientation to HASP-II, Version 3. 


HASP NEWSLETTER #13 
Page 4.1 


HASP-II, VERSION 3.0 





CHANGE GUIDE ~ | 26 FEBRUARY 1971 
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HASP-II, VERSION 3 GUIDE 
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A.O INTRODUCTION 


The objective of this Guide is to help individuals become 
acquainted as rapidly as possible with the new release of HASP -- 
called HASP-II, Version 3.0. While this Guide itself is an 
overview of changes in the system, it is intended more as a guide 
to the HASP SYSTEMS Manual, distributed with Version 3 Systems. 


An individual seeking comprehensive understanding of HASP and 
having little or no knowledge of previous versions could approach 
the Manual as follows: 


For introduction, generation, installation, operation, etc., 
read Sections 2, 24. 7sly 122.257 10el, 20:24 12.2, Itel, D227; 
P2604 sand: 12 «i 3% 


For RJE generation and operation, read Sections 7.2 through 
7.7, 10.3, 11.2 through 11.9, and 12.16. Selection of sub- 
sections in 7 and 11 should be made based upon interest in 
particular terminal type(s). 


For information about tthe internal logic of HASP, read 
Section 3 as an overview, then read selected subsections 
from 4, 5, 6, and 12, depending upon area of interest. 
Sections 8 and 9 should be used for reference while reading 
about internal logic. 


An individual who is familiar with HASP-II, Version 2 from previous 
training and/or experience can approach Version 3 much more rapidly 
than by following the extensive reading program outlined above. 

In the following, there will be reference only to specific indi- 
vidual HASPGEN parameters, tables, figures, and subsections in 

‘the Manual which best describe the differences between Versions 

3 and 2. A brief study (one day or less perhaps) of this Guide 

and the Manual references should enable an individual to generate, 
install, and operate HASP-II, Version 3; and to analyze a memory 
dump of a system containing Version 3, if that becomes necessary. 


All HASPGEN parameters are described in Section 7.1 of the Manual 
and are arranged in alphabetical order, ignoring a leading & or S$. 
The amount of descriptive material about most parameters (cross 
references to related parameters, OS requirements, etc.) has been 
increased and the default value of each iS given as part of each 
description. 
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Any parameter which is not specifically referenced in the 

remainder of this Guide is either unchanged from its meaning and 
values as in Version 2 or is changed only in minor way(s), e€.g., 
first character $ instead of &, values YES/NO instead of 1/0 or 
different default value. See E.O in this Guide for a quick method 
of re-checking all these parameters without reading about each one. 


Fach Operator's Guide is a self-contained subsection of Section 

11 in the Manual. Because some of these Operator's Guides have 
their own internal sections, references to them are made as fol- 
lows, e.g., 1ll.1- 7.3 refers to the section in the HASP Operator's 
Guide describing Special Forms Routing. 
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B.O NEW SUPPORT ITEMS 


B.a System/370 - Release 20 Support 


HASP-II, Version 3 will operate in conjunction with OS Release 20 
which provides support for the IBM System/370 in addition to 
System/360. Version 3 will also operate properly with any pre- 
vious Release of OS which is supported. 


All prior releases of HASP-II, Version 2 will remain supported 
while operating in conjunction with supported Releases of OS 

rior to Release 20, therefore, as long as Release 19 of OS 
remains supported. 


HASP-II, Version 2 will not be supported if operated with Release 
20 of OS or later releases. 





-B.b 2770 Support 


HASP-II, Version 3 contains support for the IBM 2770 Data Commu- 
nication System as a remote batch workstation. The supported 
configuration is described in Section 12.12.1. A 2770 Operator's 
Guide is included as Section 11.8. 


The new parameter &BSC2270 must be set to YES to include this 
Support. Changes to the RMTnn parameter allow description of the 
specific features on a particular 2770. 


2770 support, when compared with the previously available Component 
Release for HASP-II, Version 2.3, benefits from the improvements | 
described in C.e, C.f, and C.k below. However, because there is 

no performance benefit, the mechanical tab function of the 2213 
Printer is no longer supported as it was in the Component Release. 


B.c System/3 Support 


A workstation program to support the IBM System/3 as a HASP 
MULTI-LEAVING workstation is now provided. This support applies 
only to the Model 10. A System/3 Operator's Guide is included as 
Section 11.9; it contains a description of the BuPPOr eae card, 
printer, and console I/O units. 
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The HASP support is included if &BSCCPU=YES, just as for other 
MULTI-LEAVING remotes. The RMTnn parameter is changed to include 
System/3 as a Supported type. 


RMTGEN parameters for System/3 are described in Section 7.7. The 
RMTGEN procedure is unchanged, but a new System/3 remote description 
card is included in Table 10.3.3. System/3 users must order the 
Starter System (a 96-column loadable card deck) as Optional Material 
when they order HASP and use it according to Section 10.3.6 to 
obtain the output of their RMTGEN as a 96-column card deck. 


Although the System/3 workstation program must be created by 

RMTGEN from HASP-II, Version 3, it will operate properly with a 

HASP-II, Version 2.3 system which is generated to support any other 
type of MULTI-LEAVING remote with comparable configuration. 


B.d 3211 Printer Support 


HASP device support has now been expanded to include support for 
the IBM 3211 Printer. 


The UCS Buffer is loaded based upon a setting of parameter &PRTUCS 
and/or by operator command. The Forms Control Buffer is loaded by 
operator command. See the $T command in 11.1- 1.7. 


The new functions of the &PRTUCS parameter and the ST operator 
command also apply to loading of the UCS Buffer for 1403 Printers. 


Bee 3330 Disk Support 


The HASP direct-access allocation facilities have been expanded 
to accommodate the increased capacity of the IBM 3330 Disk Storage. 


Parameters &NUMDA and &NUMTGV affect use of 3330s and other DASDs 
by HASP. Rotational Position Sensing is not utilized by HASP. 
see also C.j below. 


B.f 2260 Support 


Basic support is now included to operate the IBM 2260 Display 
Station as a local HASP console. The support applies to any 
model of 2260s (and associated 1053 if any) attached to a local 
2848 control unit. | 
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This support is available only if HASP is controlling all consoles 
(&NUMCONS>0) and is included by setting new parameter &SI2Z2260 to 
the screen width of the 2260s, either 40 or 80. New parameter 
&SPD2260 is set to control the rate of message display on 2260s. 


Operation of the 2260 as a HASP console is described on a single 
page in Section ll.1l - 5.1. 
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C.O INCREMENTAL IMPROVEMENTS 
Cia System Restructure 


HASP has now been segmented into multiple functional assembly 
modules. Many HASP macros are now separate source members. A 
source member for the System/3 remote program has been added. 


This restructuring includes a complete re~numbering of the HASP 
source statements. The sequence numbers of each member begin 
with one or two unigue alphabetic characters so aoa PTFS cannot 


be mistakenly applied to a wrong member. 











Table 10.1.1 shows all the source members of the distributed 
HASP System. During HASPGEN, 14 of these are assembled to 
produce the 14 object modules shown in the table as members of 
SYS1.HASPOBJ. Table 10.1.4 describes the jobs in the first tape 
file used for a complete HASPGEN. They are very similar to the 
first file of the Version 2 tape, except that there are several 


more assemblies. 


Ten of these modules are later combined to form the main HASP 
vrogram. The contents of each is described below, approximately 
in the order of occurrence in the assembly listing or in a storage 
dump. The majority of names of processors, programs, and control 
blocks will be familiar td experienced HASP-II, Version 2 users. 


HASPNUC contains: 


HASP Communication Table (HCT) 

Control Services Subprograms called by HASP macros 
Channel End Appendages 

Asynchronous I/O Processor 

Timer Processor 

Overlay Roll Processor 

Trace Routines (if &TRACE>0) 

Processor Control Elements (PCEs) 


HASPRDR contains: 


Input Service Processor 
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HASPXEQ contains: 


Execution Control Processor 

IOS (SVC 0) Interface 

OS RDR JCL Exit 

LINK/XCTL Intercepts 

Thaw Processor 

Log Processor 

Data Definition Tables (DDTs) 
Partition Information Tables (PITs) 


HASPPRPU contains: 


Output Service (Print/Punch) Processor 


HASPACCT contains: 


Accounting Card Subroutine (if &ACCTNG=YES) 


HASPMISC contains: 


Purge Processor 

Execution Task Monitor Processor (if &MONINTV>0) 
Checkpoint Processor and IOB 

HASP Job Queue and Checkpoint Record Area 

Job Information Table (JIT, if &JITSIZE>0) 
Priority Aging Processor (if &PRIRATE>0) 


HASPCON contains: 


Console Buffering and Queueing Subroutines 
WTO/WTOR (SVC 35) Interface 

Reply Elements (if &NUMCONS>0) 

WTL (SVC 36) Interface (if &WTLOPT=YES) 
Console Attention Processor (if &NUMCONS > 0) 
Attention Appendage 

Console I/O Processor and IOBs (if SNUMCONS? 2) 
HASP. WTO Task (if &NUMCONS=0) 

OS MGCR (SVC 34) Interface (if &NUMCONS=0) 


HASPRTAM contains: (if &SNUMLNES>0O) 


RTAM Subroutines 

Code Translation Tables 

Line Manager Processor 

Remote Console Processor 

Message Allocation Control Block (MSA, if &SPOLMSG>0) 


-HASPCOMM contains: 


HASP Command Processor 
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HASPINIT contains: 


Master Track Group Allocation Bit Maps 

Printer Checkpoint Elements 

Device Control Tables (DCTs) 

DCBS, DEBS 

Console Message Buffers (CMBs) 

Overlay Areas, each with IOB 

TP Buffers, each with IOB (if &NUMLNES>O) 

Line and Remote Definitions (if &NUMLNES>0) 

Dump Programs (if &DEBUG=YES and/or &DMPTAPE>0) 

Assembled Buffers, each with IOB 

Initialization Coding (physically in the preceding 
Buffers) | 


The four other assembled modules are link edited separately from 
the main HASP program. | 


HASPBR1 is used to ATTACH the HASP WTO Task whose coding 
is actually in HASPCON (when &NUMCONS=0). See also C.d 
below. Although the executable coding of BR1 is only 
two bytes long, its listing contains the most complete 
documentation of all HASP Control Blocks. 





HASPSVC is link edited into the OS Nucleus and performs 
the same function as (but is not compatible with) HASPINIT 
in Version 2. y 


HASPWTR is ATTACHed aS a separate Task if &WTRPART=*. 
See also C.h below. 


HASPOBLD is a utility used only as a pre-processor when 
link editing the 10 modules of the main HASP program. 
See C.b below. 


Later comments in this Guide will further highlight the more 
important internal changes related to the restructuring. 


e 
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C.b Overlay Structure 


An overlay capability has been added such that selected sections 
of HASP may optionally be made resident on direct-access storage 
and fetched into a dynamic area within HASP to perform their 
required functions. 


Sections of code in several of the 10 main assemblies are selected 
for potential overlay by use of the SOVERLAY macro, which causes 

a section of code to become a separate CSECT within its assembly. 
These CSECTs are then written to an overlay data set for Subsegquen:. 
use. During HASP processing, a requirement for an overlay routine 
(indicated by a SLINK, SLOAD, or SXCTL macro) invokes HASP 

Overlay Services to fetch the required overlay. The overlay 
routine is later released by use of a SRETURN or S$DELETE macro. 
For a routine to be used as an overlay segment, it must be 
re-entrant (in the HASP sense), and location independent (movable 
during execution). 


The new parameter &NUMOACE specifies the number of fixed size 
(currently 1024 bytes) overlay areas assembled into HASP for use 
as dynamic areas to contain overlay sections during processing. 
New parameter &OLAYLEV provides a means of making certain sections 
permanently resident and not subject to dynamic fetching. 
&NUMOACE=1 1s probably adequate for M40 and M50 users. Also, the 
default value &OLAYLEV=15 (meaning all overlay sections disk 
resident) is probably adequate for most users. To improve overlay 
performance for large systems, it is probably wiser to increase 
&NUMOACE to three or four before decreasing &OLAYLEV from 15, 
thereby making more important overlays permanently resident. 





The process of combining the 10 assemblies into the main HASP 
program is now a multiple step operation, best described by 
Sections 10.2.2.3 and 12.1.3 of the Manual. Briefly, the HASPOBLD 
utility reads all the object decks, extracts overlay CSECTS writing 
each as one record in the overlay data set, resolves inter-CSECT 
references to overlays, and passes resident CSECTs to the standard 
OS Linkage Editor which creates the HASP load module. Control 
cards to HASPOBLD may be used to override the effect of S&OLAYLEV 

on any overlay routine. | 


The HASPOBLD listing shows each overlay and its disk address. The 
Linkage Editor listing (when &OQLAYLEV=15) shows one resident CSECT 
from each of the 10 assemblies and the HASPOTAB CSECT, created by 
a HASPOBLD and used during processing to reference overlays on 
( _ direct-access. | 
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Sections of HASP chosen for overlay are those with the least 

impact on system performance: initialization and termination 

logic of Input, Execution, and Output Processors; Operator Command, 
Checkpoint, Purge, Execution Task Monitor, Priority Aging, and 
Remote Console Processors; Accounting Subroutine; and sections 

Of Initialization. 


C.c Improved Operator Command Facilities 


The HASP Operator Command Processor has been rewritten to pro- 
vide a more flexible command format, a more powerful command 
set, abbreviation capabilities, and full use of the overlay 
capability in HASP. 


The new command format begins with a $ (of course) followed by 

a single character verb, followed by one or more operands 
separated by commas (see Section 11.1 - 1.1). The verbs are 
listed alphabetically in Table 11.1 - 1.1.1. As can be seen 
from that table, in many cases a HASP verb has a meaning similar 
to the same single letter used as an OS command abbreviation. 





Table ll.l - 1.1.2 illustrates the partial compatibility provided 
for the Version 2 long form of HASP command verbs. The long verbs 
are replaced by the characters shown for the equivalent short 
verbs, then the operands are interpreted. Most new verbs replace 
only a single old verb. However, ST, $D, and SP each replace 
several old verbs. 


Operand formats for most single references to jobs and devices 
are unchanged, e.g., SA JOB5 or $P LNE2. Examples in 
Table 11.1 - 1.1.2 show some of the more notable changes in 
operand format: "In" must be used for HASP logical initiators 
in both MFT or MVT;. syntax for altering job priorities, setting 
initiator classes, and single spacing the printer is changed; a 
HASP input tape is asSigned a unit address and started by a 
Single command. | 


The new commands are not just changed a little but also have 
Significant new capability. Table 11.1 - 1.1.3 best summarizes 
the total capability of all commands in seven functional groups. 
The Job List commands each allow lists of one or more jobs and/or 
ranges of job numbers. The Device List commands allow multiple 
devices in a single command. The SF and $I commands are 

. completely new (see also C.0). Individual Remotes and Lines may 

{ | now be displayed. Finally, the response to any commands which 

refer to jobs or queues is now systematized as described in 
Section 11.1 - 1.3. 
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The entire HASP Operator's Guide has been rewritten. For example, 
Sections 11.1-6 and 7 approach the commands from a functional 
standpoint rather than as individual commands. However, a working 
knowledge of most new commands can be gained from a review of the 
three above referenced tables alone, especially Table 11.1 - 1.1.3. 
One of the Job List commands should be reviewed in Section 11.1 - 1.5 
to learn the freedom of the job number range operand format. The 
ST device command should be studied in Section 11.1 - 1.7 because 
of its great variety of options. Sections 11.1 - 1.4 through 

1.10 provide detailed material about all commands and are intended 
primarily for operator reference rather than straight through 
reading. 


The control of console devices has been improved considerably. 0s 
console support can be used (&NUMCONS=0, see C.d) or HASP console 
Support can be used if the device type(s) are limited to those 
listed under &NUMCONS. 


HASP messages in previous versions were routed to logical console 
designations and given importance levels (as shown on the second 
page of 11.1- 5.1) but the correpondence between physical (CON1, 
CON2, etc.) and logical (UR, MAIN, etc.) consoles had to be altered 
by assembly changes (previously described in HASP Newsletter #11, 
page 2.4). Now this correspondence and the importance level can 
both be set by the $T command (third page of 11.1- 5.1). Table 
ll.1 - 5.1.1 gives the logical routing of all HASP messages. 

These routings have been revised to allow greater "separation" of 
messages by logical console. 


New parameter &CONAUTH and the $T command provide for limiting the 
types of commands which can be entered from HASP consoles. 
Section 11.1, page 127 gives further information. 


Though not required for understanding and use of Version 3, 
Section 4.5 of the Manual may be read for further information 
about the Command Processor. Its internal logic has been designed 
to facilitate addition of new commands. | 


C.d Improved OS Console Interface 


Installations may now utilize OS console support rather than 
the HASP support and still retain HASP Remote Console Support, 
direct entry of HASP commands, short form REPLY, input stream - 
HASP commands, and the auto-reader feature (Release 19 or later 
for MFT Systems). 
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The OS SYSGEN macro SUPRVSOR for an MFT System must contain the 
OPTIONS= (ATTACH, TRSVCTBL,...) and RESIDNT=(TRSVC,...) parameters 
in order to use this feature. ATTACH need not be resident. 


The new parameter &NUMCONS (replaces &NUM1052) should be set to 

zero to use this interface. OS will then physically support all 
consoles, subject to features included in the OS SYSGEN. The 

Notes under &NUMCONS give further important information, especially 
the requirement to set &NUMCONS=0 when HASP is used with the MCS, 
M6O5MP, or TSO options of OS. See also Section 12.7 for restrictions 
concerning console support. 


With OS controlling all consoles, such functions as establishing 
correspondence between physical and logical consoles and setting 
authority of certain consoles to enter commands is performed by 
using the OS VARY command, as described in appropriate OS docu- 
mentation. Section 11.1 - 5.2 describes the equivalences between 
OS and HASP logical consoles and OS and HASP console authority 
which are assumed when &NUMCONS=0, for purposes of HASP message 
output and HASP command input respectively. A special case of the 
ST command (described in Section 11.1, page 57) is provided to set 
the message importance level for HASP logical consoles when 
&NUMCONS=0 (rather than for physical consoles as with HASP console 
Support, see 11.1 - 5.1), because OS has no equivalent function. 


When &NUMCONS=0, a Separate HASP WTO Task is created by ATTACHing 
load module HASPBR1. This module branches immediately to coding 
which physically exists in module HASPCON but which continues to 
operate as a separate task. The primary motivation for this 
Separate task is to issue WTOs for all HASP messages. If OS 
forces this task into a WAIT condition when there are no WTO 
buffers, the main HASP Task will not lose dispatchability. Though 
not required for understanding and use of this feature, Section 
12.15 of the Manual may be read for further information about all 
the interfaces with OS console support. 


C.e Punch Special Forms 


® 


Special forms may now be specified for SYSOUT data sets which are 
to be punched. 7 


To use this feature, pseudo 1442 UCBs must be provided by OS 
SYSGEN (see Section 10.2.1.1) just as pseudo 1443s are provided 
for print special forms. See also C.f. 
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C.f Improved SYSOUT Forms Routing 


Users may optionally cause grouping of SYSOUT data sets by forms 
type to minimize printer setup time. 


Two new values (1 and 2) are allowed in specifying the meaning of 
various SYSOUT classes using the $$x HASPGEN parameter. When 
classes set to these values are used (J and K are the defaults), 
the data sets are not printed or punched with the rest of the 
job's standard output. 


After standard printing, a job is re-queued and then available 
only to a printer or punch conditioned for special forms routed 
processing of the particular form number specified in the SYSOUT. 
When printed or punched, such a data set will be processed with 
all other data sets from the same or other jobs, requesting the 
same form number, which are in the queue at that time. 


After all special forms routed printing and punching is completed 
(which may require several re-queueing operations for different 
form numbers), the job proceeds to standard punching. 


The conditioning of printers and punches to do special routed 
output is controlled by the $T command and described in Section 
lil.l- 7.3. Special considerations for 2780 and 2770 terminal 
operators are given in the "Central Computer Control" Sections 
of Sections 11.7 and 11.8. 


For 3211 printers, the operator may reset the FCB with ST when 
setting a new forms type. For 1403 and 3211 printers, the UCHS 
may be reset as part of "forms mounting" if a new chain/train is 
mounted. 


Processing of standard output classes (usually A and B) requesting 
Special forms operates just as in Version 2, i.e., forms must be 
mounted and dismounted from one data set to the next during printing 
or punching of that job. If the forms field in the JOB card is 
used, all print data sets without special forms will use that 

form number and be subject to the new special routing. 


See 12.7 for a restriction on characters in the forms field. 
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C.g MFT Dynamic Dispatching 


The Dynamic Dispatching capability in HASP, previously restricted 
to MVT Systems, may now also be used with MFT Systems (Release 19 
or later). 


The OS SYSGEN macro SUPRVSOR must contain the OPTIONS=(ATTACH,...) 
and TIMER=JOBSTEP parameters if the MFT System is to Support this 
HASP feature. ATTACH need not be resident. 


The inclusion of this feature in HASP is controlled, as previously, 
by the parameter &MONINTV. Two new parameters, &XZMFTH and 


&XZMFTL, control the range of MFT task priorities to be included 


in the dynamically dispatched group. Because of the potential 
benefit and negligible overhead of this feature for most instal- 
lations, the default values for these parameters (and the 
&XZPRTY and &PRI parameters for MVT Systems) are set such that 
most jobs executed under HASP control are subject to Dynamic 
Dispatching. 


The internal algorithms for adjusting dispatching priorities every 
&MONINTV seconds remain the same as in Version 2. 


C.h Elimination of OS Writer Requirement 


HASP now optionally provrdes a minimal module to interface to the 
OS job queue which eliminates the previous requirement for a 
resident OS writer in both MVT and MFT (Release 19 or later for 
MFT Systems). 


The OS SYSGEN macro SUPRVSOR for an MFT System must contain the 
OPTIONS=(ATTACH,...) parameter in order to use this feature. 
ATTACH need not be resident. 


To use this feature, parameter &WTRPART should be set to *. The 
default value is set this way, since most installations will want 
to eliminate the OS writer partition. The new parameter &WIRCLAS 
specifies one to eight MSGCLASSes which are processed from the 

OS job queue by either the HASP Writer module or the OS writer. 
HASP continues to supply a valid MSGCLASS parameter for jobs 
which omit this parameter or use one which is not in &WTRCLAS. 
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The new parameter &WCLSREQ may be used to activate a feature 
available only with the HASP Writer. After being processed to 
terminate a job's execution, SMBs of certain classes in &WTRCLAS 

may be re-queued for processing by other system writers. As an 
example, this feature might be used with terminal systems which 
have been modified to submit jobs through the HASP Internal 
Reader interface. | 


C.i Execution Job Batching 


Jobs may now be automatically grouped by class and passed | 
directly to an executing job such as a one-step monitor or other 
direct job pracessor. 


This optional feature is included by setting new parameter 
&XBATCHC to a list of job classes to be scheduled in this special 
Way. New parameter &XBATCHN is used to specify jobnames reserved 
for internal use with this feature. 


Section 12.13 describes requirements of batch processing programs 
and special actions necessary to install and use this feature. 


C.j Improved SPOOL Disk Allocation 


Space on SPOOL disks is now dynamically allocated by logical 
track groups rather than by physical cylinders. Each bit in 
the HASP allocation map now represents a HASPGENable number of 
‘direct-access tracks. 


New parameter &NUMDA specifies the maximum number of SPOOL 
volumes to be used and replaces parameters &MAX2314 and &MAX2311. 
Mixtures of supported device types are permitted and the capa- 
Cities of each are used to their fullest. Old parameter 

&NUMCYL is replaced by new parameter &NUMTGV which divides each 
volume, regardless of type, into the same number of track groups. 
The size of a track group depends upon the device type and 
&NUMTGV; e.g., if &NUMTGV=400, then a track group contains five 
tracks on a 2311, 10 tracks ‘on a 2314, and 19 tracks on a 3330. 


A Single extent data set named SYS1.HASPACE must now be allocated 
on each SPOOL volume prior to starting HASP. Only space within 
this extent will be used. Recommended procedures are discussed 
in Sections 10.2.2.4 and 12.1.4. HASP-II, Version 2 allocated 
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SYS1.HASPACE data sets itself so that in most cases such volumes 
may be used immediately with Version 3. However, Version 3 cannot 
be warm started using SPOOL volumes last operated under Version 2. 


The HASP form of direct-access addresses is still four bytes 

long, but has been changed to accommodate the larger capacities 

of the 3330 and the track group concept. Figure 3.2.2 illustrates 
the new form of address. 


C.k Non-MULTI-LEAVING Terminal Console Support 


Users at non-MULTI-LEAVING remote workstations (2780, 2770, 
1978, STR Model.20, etc.) may now receive responses to HASP 
commands submitted through the remote card reader. 2770 users 
may also submit commands from the standard keyboard. 


This feature is included by setting new parameter &SPOLMSG to 

the number of records on SPOOL] reserved for operator messages 

to be returned to these terminals. A description of this fea- 
ture has been added to the end of the "Central Computer Control" 
Sections of Operator's Guides for the 2780 and 2770 (Sections 11.7 
and 11.8). 


The commands available are those valid from a remote source as 
indicated by Table 11.1 - 1.1.3. In addition to command 
responses, the terminals also receive the "JOB} ON device --" 
message, from jobs submitted, and messages from other operators 
in the system, created by use of the $DM command. 


C.1 Improved SMF Compatibility 


Provision has now been made to allow SMF to count I/O requests 
for pseudo devices. This function does not depend upon any 
HASPGEN parameter and is activated automatically if HASP detects 
the presence of SMF in the host MFT or MVT System. 


C.m Priority Aging 


Installations may optionally cause the priority of jobs to 
increase in proportion to the length of time the job has been in 
the system. 
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To include this feature, the new parameter &PRIRATE should be set 
to the desired amount of priority increase in a 24 hour period. 
New parameters &PRIHIGH and &PRILOW provide a means of limiting 
the range of job priorities which are affected by aging. 


C.n Variable Buffer Pool 


ee CD tS 


The number of buffers in the HASP Buffer Pool may now be dynam- 
ically varied by changing the HASP region or partition size. 


As in Version 2, the parameter &NUMBUF controls the number of 
buffers assembled as part of the HASP load module. During HASP 
Initialization, additional buffers are built in all available 
storage of the hierarchy indicated by new parameter &BUFHICH. 
However, new parameter &RESCORE allows reserving a portion of 
storage for other OS functions. New parameter &MINBUF provides 
a means of warning the operator if &NUMBUF plus the additional 
buffers do not provide a minimum number of buffers. 


C.o Additional Print Control 


Tceoaiuemeamanmne hanna ennnumnatententamaimmaamnemmaansimamnen cme guedineneceammnmcaraaanad 


The operator now has the capability to both forward and backward 
space print data sets a variable number of pages. Print jobs 
may also be suspended during processing and resumed at a later 
time. 


These functions are implemented by the SF, $B, and SI operator 
commands, which are described in Section 11.1 - 1.7. For SF 
and $B, the next forward or backward data set boundary may be 
specified, rather than a number of pages. 


For 2780 and 2770 terminals only, an optional feature (included 
by setting &BSHPRSU=YES) is available which allows the operator 
to simulate a $I function by simply stopping and starting the 
terminal printer. Operator commands and/or jobs may be trans- 
mitted to HASP before printing resumes. See the end of the 
"Error Recovery When Receiving" Sections of Operator's Guides 
for these terminals (Sections 11.7 and 11.8) for a description 
of this feature. 


C.p Withdrawable HASP 


An operator command is now provided to cause HASP to withdraw 
from the system leaving OS in an operational state. 
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The command S$SPHASP is issued, when HASP is in an ALL AVAILABLE 
FUNCTIONS COMPLETE state, to cause the withdrawal. Another 
HASP may then be started or the same HASP may be started, per- 
haps with a different partition size; see C.n above. 


The command is described in Section 11.1 - 1.8 and certain 
restrictions on its results are given in Section 12.7. 


C.q Inclusion of All Previous Maintenance 


All previously reported problems have been corrected in this 
version. All previously distributed PTFs through number DPA2273 
have been logically integrated into the source coding. 


Previous modifications, which were separately available, to 
improve operation in an MP65 System are also logically included 
and do not require any special HASPGEN parameter settings to 
function. | | 3 
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D.O MISCELLANEOUS CHANGES, REQUIREMENTS, ETC. 
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The following HASPGEN parameters, in addition to those already 
mentioned, are new or significantly changed. 


&OSINOPT when set to YES causes data sets begun by DD * and 
DATA which include a DCB parameter to be passed to OS for 
SPOOLing as temporary disk data sets. This feature may be 
used to provide re-readable input data sets, concatenation 
of "like" attribute data sets, etc. : 


&DMPTAPE specifies a tape address and inclusion of an 
optional high speed dump-to-tape program for use at system 
failure time. The tape produced may be printed using 
service Aid IMDPRDMP. 


&NUMLNES is now the controlling parameter for inclusion of 
RJE support, rather than &NUMRJE. These two parameters are 
otherwise unchanged. | 


SPRTBOPT, SPUNBOPT, SRPRBOPT, and SRPUBOPT all replace 
&PBUFOPT in specifying the buffering logic of Print/Punch 
Processors. The defaults (all single buffering except local 
printers which are double) are probably best for most 
installations. 


&O0SC(n) now specifies the internal classes of jobs passed 
to OS for MVT Systems (thereby replacing &MVTCLAS) as well 
as for MFT Systems. Now only one MVT initiator will be 
POSTed for each job passed to OS. 


SPRICONA now specifies the hardware console address for HASP 
CATASTROPHIC error messages, which always indicate system 
failure. These messages previously went to HASP CONSOLE1. 
Also, this type of message will now result if HASP is 
ABENDed by OS for any reason (STAE exit is used), increasing 
the probability of a valid memory dump taken at that time. 


Old parameters have been eliminated: &TIMER (HASP now assumes 
at least TIMER=INTERVAL in OS), &MAXERR (HASP console error 
retries are now fixed at 4), and &SSTART (all assemblies 

begin at. origin zero). 


New parameter &OREPSIZ must be set to some value greater 
than 10 if the HASP repping facility, standard for resi- 
dent CSECTs, is to be available for overlay CSECTs. 





Dae 
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Certain 1130 RMTGEN parameters have been added, or have had default 
values changed, see Sections 7.5 and 7.6. 1130 RMTGEN has been 
improved and now produces an assembled instruction listing with 
correct 1130 instruction format. Other workstation programs are 
unchanged except for inclusion of previous PTFs and re-numbering. 


HASP-II, Version 3 requires that the following engineering 
changes be installed, in order to support the 2780 terminal. 


Device ECA FC 
2701 109 306749 
2703 65 307702 


ETX, EOT is now sent to the 2780 at the end of each job's printed 
or punched output. This makes possible automatic turnaround from 
print to read. See the end of Section 11.7 - 2.1.1. 


Punch error recovery and pocket selection have been generalized 
to support the 2520 and 1442 punches. 


Jobs which are failed or cancelled prior to execution now produce 
a listing indicating the nature of the error. 


Jobs may now be referenced by operator commands while being read 
into the system. 


The HASP Dispatcher has been re-coded to reduce CPU time required 
for scanning PCEs, especially for large configurations. 


Section 12.7 of the Manual should be reviewed for General Restric- 
tions about the use of HASP-II, Version 3. 


As indicated by Section 12.2, the basic storage requirements of 
the HASP load module have been reduced by approximately 6700 bytes, 
despite substantially increased functions, e.g., in the area of 
operator commands, special forms, etc. Many optional features 
now require less storage than previously. Use of the HASPWTR 
module results in an additional storage saving of from 6K to 10K 
when compared with a previous MFT System (without ATTACH but 

with a writer partition) or MVT System (with a writer region). 
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E.O INITIAL INSTALLATION STRATEGY 


Many installations will want to install a test HASP-II, Version 3 
System as rapidly as possible, to gain familiarity and first hand 
experience with it, while working toward a production Version 3 
System including, perhaps, re-integration of local modifications. 
The following suggestions may aid such an effort. 


For HASPGEN, the suggested data set allocation deck is the same 
except that BLKSIZE=400 is recommended for SYS1.HASPOBJ. A trial 
HASPGEN (run only the first job in the first tape file, use no 
parameters, reply ‘'end' to the WTOR) will produce a complete list- 
ing Of all HASPGEN parameters with defaults. All parameters not 
specifically mentioned in this Guide should then be checked and 
changes made as required to the previous HASPGEN parameter deck 
because of new defaults, first character $, or YES/NO values. 
Parameters specifically mentioned previously in this Guide should 
be reviewed in Section 7.1 and values for them should be chosen. 
Finally, after re-running the data set allocation, the complete 
HASPGEN should be performed using the parameter deck, and using 
Table 10.1.4 and Section 10.1.4 for guidance. 


The new HASPSVC must be installed in the OS Nucleus (see 10.2.2.1 
and 12.1.1) since it is not compatible with the old one. If more 
than one Type I User SVC slot was specified in SYSGEN, the new 
SVC can be installed without disturbing the old one by using a 
different value for &INITSVC. 


The new procs must be installed (see 10.2.2.2 and 12.1.2). The 
new RDR and WTR procs have different names, so no conflicts occur 
with old ones. The new HASP proc should replace the old one. 

By proper naming of the STRTHASP jobs (old and new) and use of 
the JOB= keyword, both old and new HASPs can be started under the 
same system. | 


The job to install the HASP overlay data set and load modules has 
already been referenced (see C.b, 10.2.2.3, and 12.1.3). The HASP 
load module name may be changed (corresponding change in STRTHASP 
job reguired) to avoid conflict with an old HASP in SYS1.LINKLIB. 


See C.j for comments about old SPOOL disk use. Specify FORMAT 
when using a SPOOL disk under Version 3 for the first time. 


For RJE users, the Version 2.3 workstation programs will operate 
correctly with Version 3. However, a new RMTGEN with Version 3 
is recommended to insure that all latest maintenance is included. 
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FLO SYSTEM MAINTENANCE HINTS 
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F.a The Storage Dump Containing HASP 


Although Version 3 may appear to be greatly changed by restructure, 
overlay, and a completely new command set, the logical organization 
presented in a storage dump is very similar to Version 2. A few 

of tne more significant differences will be highlighted here. 


If the dump has OS control blocks formatted, e.g., as printed by 
IMDPRDMP, the multiple task structure of HASP will be apparent. 
The main HASP task uses the main load module (usually named HASP). 
If &NUMCONS=0, a subtask using HASPBR1 should be present. If 
&WTRPART=*, a subtask using HASPWTR should be present. 


The beginning of the main load module can be found by looking in 
the lower part of the HASP region for the version number " V 3.0" 
in EBCDIC. Then by using the link edit listing (produced as 
described under C.b), each of the resident CSECTs (normally one 
from each of the 10 main assemblies plus HASPOTAB) can be found. 


The first part of CSECT HASPNUC (which is usually first in the 
load module) is the HASP Communication Table or HCT. This is 
documented in Figure 8.1.1 but is best seen in the HASPNUC 
assembly listing. It begins with a series of branches to HASP 
Control Service Subprograms (new with Version 3) and contains 
most of the globally used status bytes, counters, control block 
chain pointers, and queue pointers which were in roughly the same 
area of a Version 2 listing. Other assemblies expand an HCTDSECT 
which allows them to call Control Service Subprograms by branching 
to the branches in HASPNUC and to reference the other HCT cells 
directly. ENTRY, EXTRN, Vcon type referencing is used for other 
inter-module communication. 


The PCEs are now in module HASPNUC, rather than toward the end 

of HASP. The first one can be found by looking in cell $PCEORG in 
the HCT or by* following the OS save area chain from the system 
provided first save area. PCES are now chained together exactly 
like OS save areas: forward chain in word 3, back chain in ‘word 
2. In fact, HASP now uses this forward chain as its PCENEXT or 
dispatching chain. This same chain is, of course, used when 
analyzing the state of all HASP Processors in a storage dump. The 
other major PCE dispatching fields, i.e., re-entry address PCERIS5 
and dispatchability PCEEWF, are logically unchanged. 
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The order of things in the remainder of the dump is very similar 


but not identical to Version 2. The description in C.a may be 
used as a guide to the contents of the various CSECTs, to deter- 
mine which assembly listing is needed when investigating a 
specific portion of a dump. 


The other major control blocks (DCTs, DDTs, PITs, JCTs, JQEs, 
JITs, CMBs, Buffers, etc.) have only had minor bit re-definitions 
in Version 3. Pointers to the various chains of these elements 
are in the HCT. 


It may be desirable to analyze the overlay status of HASP when 
working on an undetermined problem. The overlay areas should 
first be inspected. 


A pointer to the first area can be found in cell SOACEADR 

in HASPNUC. All area control fields are defined in BUFDSECT. 
Subsequent areas are chained from OACECHN of the previous 
area. 


The CSECT in each area can be determined by looking at 
OACENAME (which is the first four bytes read from disk) 

for the last three or four characters of the CSECT name. 
OACEOCON also identifies the routine assigned to the area. 
OCONS can be interpreted by looking at the listing produced 
by HASPOBLD. 


If any PCEs are using the routine, OACEPCE will be non-zero 
and point to the first of a chain of PCEs. 


If BUFECBCC is zero, an uncompleted read operation was in 
progress to load the routine from disk. 


Once the status of overlay areas is known, PCEs should be inspected 
for possible use of overlay. 


A PCE which is using a routine currently in memory shoulda 

be on a chain which begins with OACEPCE of an area and con- 
tinues through PCEOPCE of one or more PCEsS. PCEOCON of each 
should match OACEOCON. 


If a PCE is not on an area chain but does have the SEWFOLAY 
bit on in its PCEEWF, it should be on a queue beginning at 
cell SWAITACE in HASPNUC. This queue continues through : 
PCEBASE3 of subsequent PCEs. Side chains of other PCEs from 
PCEOPCE may be present if several PCES have equal PCEOCONS 
(requesting the same routine). 
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A PCE which has the SEWFOROL bit on in its PCEEWF is not on 
any chain (PCEOPCE is not meaningful) but its PCEOCON 
indicates the requested routine. PCER15 may be a very small 
value which then represents the relative displacement into 
the routine at which execution will later resume. 


PCEORTRN contains the return address from the original SLINK which 


invoked overlay. A PCE not in one of the three above states is 
not using overlay and its PCEOCON is not meaningful. 


F.b Service Aids 


The optional &DMPTAPE facility has already been mentioned in D.O 
as an alternative to IMDSADMP. Output of either can be printed 
with IMDPRDMP. 


ABEND of the main HASP task is now un-equivocally indicated by 


a "CATASTROPHIC" error message with "CODE = ABND". A dump taken 


then should show the HASP task structure and region intact, with 
completion code in the TCB. 


-HASP REPing at initialization time is a standard feature for 


resident CSECTs, but &OREPSIZ must be set to reserve a small 
amount of storage if REPing of overlay CSECTs is desired. REP 
cards may specify absolute storage locations or locations in any 
CSECT, as taken from assembly listings. See Section 6.4.1 for 

a description of the new REP card format. 


Permanent machine language patching may be performed using 

IMASPZAP. Resident CSECTs in the load module may be ZAPed using 
familiar NAME, VERIFY, and REP cards. Resident CSECTs are usually 
assembled at zero so that listing addresses may be used. A patch area 
at symbol SPATCHSP in HASPNUC is provided and is reachable by any 

code with HASP BASE] addressability. 


For ZAPing overlay CSECTs, the SYSLIB card should reference 

the sequential overlay data set. The example below shows control 
cards that may be used. The address for the CCHHR is taken from 
the listing produced by HASPOBLD. BASE adjusts for non-zero 
assembly origin of the CSECT. Most overlay CSECTs are shorter 


then the overlay record size of 1024 bytes. The space in the 


record following the last assembled location of the CSECT may be 
used as patch area. ABSDUMP cards may be used to dump the 


entire overlay data set or Single CSECTs. 
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CCHHR OOOAN00501 
BASE — 0007A8 
VERIFY 000824 47F0,8236 
REP 000824 4780,8242 


F.c HASP APAR Information 


HASP APAR information is placed in RETAIN under the program 
number 360D51014. Most PTFs are few enough source cards to be 
contained in the RETAIN entry. 


Information purged from RETAIN is placed in Early Warning 
microfiche, group ZP, and Programming Systems Memoranda, Group 48. 


As in the past, it is strongly recommended that all PTFs which 
may become available for HASP-II, Version 3 be installed at the 
earliest convenience, whether specific symptoms have occurred or 
not. The procedure for PTF installation is described in 

Section 10.1.3. 
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5.0 HASP - VERSION 2.3 -— MAINTENANCE SUMMARY 
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The following is a summary of all current PTFs relevant to the 
Version 2.3 system. It is recommended that, to avoid duplicate 
effort, all applicable PTFs be applied to HASP immediately, even 
if the problem described has not been encountered. Detailed 
information concerning the APARs listed below and, in most cases, 
the actual program fix, can be found in the RETAIN information, 
the early-warning microfiche (group ZP), and/or Programming 


System Memoranda (group 48). 


symptom 


Number 

.PAN093 1130 Text Compression problem 

PA0N094 SDRAIN/SSTARTIne/error recovery may cause Abend 
PA0N096 Pseudo device protection 

PA0NO098 CCW count of zero fails 

PAQ1OO REQUIRED FOR SUPPORT OF 2780s 

PAO461 Special forms problem if STPIDCT=0 

PA0464 SLI not simulated in CCW 

PAO477 Loop if pseudo-units on SYSRES channel 

PAQ479 1130 problem if punch-only 1442 

PAO 886 Abnormal channel-end appendage error 

PA0888. SROUTE error 

PA0889 Mod/20 XIO loop 

PA0N 898 NOP CCW gives early 2540 EOF 

PA0N900 REQUIRED FOR USE WITH RELEASE 19 SYSTEMS 

PAL221 Loop if EXCP to a line gives SIO CC=3 

PA1225 OCx if PIB CSCB pointer = 0 

PA1226 OCx in XTHAW 

PA1230 Wrong message if printer error 

PA1237 1130 I/O device loss 

PA1238 Bad backspace on big SYSOUTS \ 
PA1240 Permanent wait on warm start | 
PA1590 Premature job termination (SMB Swap) | | 

PAL598 Warm start fails if SPOOL disk order changed 
PA1600 Mod 20 - 2152 problem 

PA1812 SDisplay disks incomplete if SWAP command used © 
PA1835 ABEND - punch uses bad JCT 

PA2273 MP65/HASP CPU conflict 





